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PPP in Frame Relay 


Status of this Memo 


This document specifies an Internet standards track protocol for 
the Internet community, and requests discussion and suggestions for 


improvements. Please refer to the current edition of the "Internet 

Official Protocol Standards" (STD 1) for the standardization state 

and status of this protocol. Distribution of this memo is unlimited. 
Abstract 


The Point-to-Point Protocol (PPP) [1] provides a standard method for 
transporting multi-protocol datagrams over point-to-point links. 


This document describes the use of Frame Relay for framing PPP 
encapsulated packets. 


Applicability 


This specification is intended for those implementations which desire 
to use facilities which are defined for PPP, such as the Link Control 
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Protocol, Network-layer Control Protocols, authentication, and 
compression. These capabilities require a point-to-point 
relationship between peers, and are not designed for multi-point or 
multi-access environments. 
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Eas 


Introduction 


Frame Relay [2] is a relative newcomer to the serial link community. 
Like X.25, the protocol was designed to provide virtual circuits for 
connections between stations attached to the same Frame Relay 
network. The improvement over X.25 is that Q.922 is restricted to 
delivery of packets, and dispenses with sequencing and flow control, 
simplifying the service immensely. 


PPP uses ISO 3309 HDLC as a basis for its framing [3]. 


When Frame Relay is configured as a point-to-point circuit, PPP can 
use Frame Relay as a framing mechanism, ignoring its other features. 
This is equivalent to the technique used to carry SNAP headers over 
Frame Relay [4]. 


At one time, it had been hoped that PPP in HDLC-like frames and Frame 
Relay would co-exist on the same links. Unfortunately, the Q.922 
method for expanding the address from 1 to 2 to 4 octets is not 
indistinguishable from the ISO 3309 method, due to the structure of 
its Data Link Connection Identifier (DLCI) subfields. Co-existance 
is precluded. 


Physical Layer Requirements 

PPP treats Frame Relay framing as a bit-synchronous link. The link 
MUST be full-duplex, but MAY be either dedicated (permanent) or 
switched. 


Interface Format 


PPP presents an octet interface to the physical layer. There is 
no provision for sub-octets to be supplied or accepted. 


Transmission Rate 


PPP does not impose any restrictions regarding transmission rate, 
other than that of the particular Frame Relay interface. 


Control Signals 


Implementation of Frame Relay requires the provision of control 
signals, which indicate when the link has become connected or 
disconnected. These in turn provide the Up and Down events to the 
LCP state machine. 
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Because PPP does not normally require the use of control signals, 
the failure of such signals MUST NOT affect correct operation of 
PPP. Implications are discussed in [2]. 


Encoding 
The definition of various encodings is the responsibility of the 
DTE/DCE equipment in use, and is outside the scope of this 
specification. 
While PPP will operate without regard to the underlying 


representation of the bit stream, Frame Relay requires NRZ 
encoding. 


3. The Data Link Layer 
This specification uses the principles, terminology, and frame 
structure described in "Multiprotocol Interconnect over Frame Relay" 


[4]. 


The purpose of this specification is not to document what is already 


standardized in [4]. Instead, this document attempts to give a 
concise summary and point out specific options and features used by 
PPP. 

3.1. Frame Format 


As described in [4], Q.922 header address and control fields are 
combined with the Network Layer Protocol Identifier (NLPID), which 
identifies the encapsulation which follows. The fields are 
transmitted from left to right. 


0 1 2 3 
01:23: 4-0 06:18:90 1 234 8 6: 1-8 9:00:4 2 3-49 061 B89 Oi 
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) | 
+ 
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22 Address | Control NLPID (Oxcf) 
—$-4$-4-4-4-4-4-4-4-4-4F-4-4-4-F-4-4-F-F 4-4-4 -4F 4-4-4 + 
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The PPP Protocol field and the following Information and Padding 
fields are described in the Point-to-Point Protocol Encapsulation 
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fade. 


3.2. Modification of the Basic Frame 


The Link Control Protocol can negotiate modifications to the basic 
frame structure. However, modified frames will always be clearly 
distinguishable from standard frames. 


Address-and-Control-Field-Compression 


Because the Address and Control field values are not constant, and 
are modified as the frame is transported by the network switching 
fabric, Address-and-Control-Field-Compression MUST NOT be 
negotiated. 


Protocol-Field-Compression 


Note that unlike PPP in HDLC-like framing, the Frame Relay framing 
does not align the Information field on a 32-bit boundary. 
Alignment to a 32-bit boundary occurs when the NLPID is removed 
and the Protocol field is compressed to a single octet. When this 
improves throughput, Protocol-Field-Compression SHOULD be 
negotiated. 
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4. 


In-Band Protocol Demultiplexing 


The PPP NLPID (CF hex) and PPP Protocol fields easily distinguish the 
PPP encapsulation from the other NLPID encapsulations described in 
[4]. 


The joining of the PPP and NLPID number space has an added advantage, 
in that the LCP Protocol-Reject can be used to indicate NLPIDs that 
are not recognized. This can eliminate "black-holes" that occur when 
traffic is not supported. 


For those network-layer protocols which have no PPP Protocol 
assignment, or which have not yet been implemented under the PPP 
encapsulation, or which have not been successfully negotiated by a 
PPP NCP, another method of encapsulation defined under [4] SHOULD be 
used. 


Currently, there are no conflicts between NLPID and PPP Protocol 
values. If a future implementation is configured to send a NLPID 
value which is the same as a compressed Protocol field, that Protocol 
field MUST NOT be sent compressed. 


On reception, the first octet following the header is examined. If 
the octet is zero, it MUST be assumed that the packet is formatted 
according to [4]. 


PPP encapsulated packets always have a non-zero octet following the 
header. If the octet is not the PPP NLPID value (CF hex), and 
Protocol-Field-Compression is enabled, and the associated NCP has 
been negotiated, then it is expected to be a compressed PPP Protocol 
value. Otherwise, it MUST be assumed that the packet is formatted 
according to [4]. 


The Protocol field value 0x00cf is not allowed (reserved) to avoid 
ambiguity when Protocol-Field-Compression is enabled. The value MAY 
be treated as a PPP Protocol that indicates that another PPP Protocol 
packet follows. 


Initial LCP packets contain the sequence cf-c0-21 following the 
header. When a LCP Configure-Request packet is received and 
recognized, the PPP link enters Link Establishment phase. 


The accidental connection of a link to feed a multipoint network (or 
multicast group) SHOULD result in a misconfiguration indication. 

This can be detected by multiple responses to the LCP Configure- 
Request with the same Identifier, coming from different framing 
addresses. Some implementations might be physically unable to either 
log or report such information. 
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Once PPP has entered the Link Establishment phase, packets with other 
NLPID values MUST NOT be sent, and on receipt such packets MUST be 
silently discarded, until the PPP link enters the Network-Layer 
Protocol phase. 


Once PPP has entered the Network-Layer Protocol phase, and 
successfully negotiated a particular NCP for a PPP Protocol, if a 
frame arrives using another equivalent data encapsulation defined in 
[4], the PPP Link MUST re-enter Link Establishment phase and send a 
new LCP Configure-Request. This prevents "black-holes" that occur 
when the peer loses state. 


An implementation which requires PPP link configuration, and other 
PPP negotiated features (such as authentication), MAY enter 
Termination phase when configuration fails. Otherwise, when the 
Configure-Request sender reaches the Max-Configure limit, it MUST 
fall back to send only frames encapsulated according to [4]. 


5. Out-of-Band signaling 


There is no generally agreed method of out-of-band signalling. Until 
such a method is universally available, an implementation MUST use 
In-Band Protocol Demultiplexing for both Permanent and Switched 
Virtual Circuits. 


6. Configuration Details 
The following Configuration Options are recommended: 


Magic Number 
Protocol Field Compression 


The standard LCP configuration defaults apply to Frame Relay links, 
except Maximum-Receive-Unit (MRU). 


To ensure interoperability with existing Frame Relay implementations, 
the initial MRU is 1600 octets [4]. This only affects the minimum 
required buffer space available for receiving packets, not the size 
of packets sent. 


The typical network feeding the link is likely to have a MRU of 
either 1500, or 2048 or greater. To avoid fragmentation, the 
Maximum-Transmission-Unit (MTU) at the network layer SHOULD NOT 
exceed 1500, unless a peer MRU of 2048 or greater is specifically 
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negotiated. 

Some Frame Relay switches are only capable of 262 octet frames. It 
is not recommended that anyone deploy or use a switch which is 
capable of less than 1600 octet frames. However, PPP implementations 


MUST be configurable to limit the size of LCP packets which are sent 
to 259 octets (which leaves room for the NLPID and Protocol fields), 
until LCP negotiation is complete. 


XID negotiation is not required to be supported for links which are 
capable of PPP negotiation. 


Inverse ARP is not required to be supported for PPP links. That 
function is provided by PPP NCP negotiation. 
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Security Considerations 


Security issues are not discussed in this memo. 
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